Requirements elicitation

In requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. ^[1] The practice is also sometimes referred to as requirements gathering.

The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.

Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.

Guidelines

Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for requirements elicitation, summarized as follows:

• Assess the business and technical feasibility for the proposed system
• Identify the people who will help specify requirements and understand their organizational bias
• Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed
• Identify "domain constraints" (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built
• Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings)
• Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded
• Identify ambiguous requirements as candidates for prototyping
• Create usage scenarios or use cases to help customers/users better identify key requirements

Problems

Christel and Kang [CRI92] identify a number of problems that help us understand why requirements elicitation is difficult:

1. Problems of scope. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
2. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility.

To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner.

References